[Build] Use magic linker symbols to specify an @rpath-relative install name when targeting pre-stable-ABI OSes.#23451
Merged
mikeash merged 4 commits intoswiftlang:masterfrom Mar 27, 2019
Conversation
Contributor
Author
|
@swift-ci please test |
Contributor
Author
|
@swift-ci please test |
1 similar comment
Contributor
Author
|
@swift-ci please test |
Contributor
|
Build failed |
mikeash
force-pushed
the
magic-symbols-for-install-name
branch
from
339170e to
6b5a7ba
Compare
Contributor
Author
|
@swift-ci please test and merge |
3 similar comments
Contributor
Author
|
@swift-ci please test and merge |
Contributor
Author
|
@swift-ci please test and merge |
Member
|
@swift-ci please test and merge |
…l name when targeting pre-stable-ABI OSes. Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14. rdar://problem/45027809
…chain. The install_name trick we are using to make sure that an application built with a deployment target new enough to *guarantee* that Swift will be available in the OS (and therefore don't need dylibs bundled) link directly to /usr/lib/swift/*.dylib, but rewrites the the library paths to be rpath-relative for older OS's (e.g., @rpath/lib/swift/libswiftCore.dylib) doesn't work for sub-minor version numbers, e.g., the tools can't distinguish between 10.14.4 and 10.14. Therefore, macOS 10.14 is both an "older OS" and a "newer OS". Hack around the primary problem caused by this---the inability of first-party Swift programs to launch on macOS 10.14.4---by treating macOS 10.14 as an "older OS" when building for the Xcode toolchain (which is used by anyone who will deploy back to an older OS, e.g., 3rd party applications) but treat it as a "newer OS" when building for the OS toolchains (which is used when building the OS itself). Fixes rdar://problem/47007519.
mikeash
force-pushed
the
magic-symbols-for-install-name
branch
from
6b5a7ba to
50a09e6
Compare
mikeash
force-pushed
the
magic-symbols-for-install-name
branch
from
50a09e6 to
26d44d5
Compare
Contributor
Author
|
@swift-ci please test and merge |
1 similar comment
Contributor
Author
|
@swift-ci please test and merge |
Contributor
Author
|
@swift-ci please test osx platform |
Contributor
Author
|
@swift-ci Please smoke test OS X platform |
This was referenced May 15, 2019
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Magic symbols of the form
$ld$install_name$os9.0$@rpath/libswiftCore.dylibtell the linker to use that install name when targeting that OS version. Use these symbols to specify an@rpathinstall name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.